Application Serial No. 10/783,478 

Amendment dated August 13, 2007 

Response to Advisory Action mailed July 26, 2007 

REMARKS 

The Office Action mailed on April 17, 2007 provided grounds for rejection of claims 
1-31. Assignee has amended independent claims 1, 20, and 21, and dependent claims 7, 13, 
23, 25, and 26. Support for the amendments can be found in the Application at least at 
0052, 0091-0095, and 0100-0105. Assignee respectfully requests reconsideration of pending 
claims 1-31, and allowance of the present application in view of the following remarks. 

I. Rejections Under 35 U.S.C. § 101 

The Office Action rejected claims 1-19, 20-26, and 27-31 under 35 U.S.C. § 101, 
indicating that the claimed invention is unsupported by either an asserted utility or a well 
established utility. Office Action, p. 2. 

Assignee respectfully traverses these rejections. As an initial matter, Assignee notes 
that MPEP 2106.01 indicates that "a claimed computer-readable medium encoded with a 
data structure defines structural and functional interrelationships between the data structure 
and the computer software and hardware components which permit the data structure's 
functionality to be realized" is statutory subject matter. 

Claims 1,20, and 21 

Independent claims 1, 20, and 21, as amended, clarify that at least one of the problems 
solved by the claims includes the formation of multiple concise account level decision 
relationships used to construct multiple concise account level decision queries used to 
perform account level decision analysis. Independent claim 1 was further amended to include 
logic operable to execute the multiple concise account level decision queries, which permits 
the functionality of the data structure to be realized. Similarly, independent claim 20 was 
amended to include a processor operable to execute the multiple concise account level 
decision queries and independent claim 21 was amended to include the execution of the 
multiple concise account level decision queries, which permit the functionality of the data 
structure to be realized. In view of the amendments to independent claims 1, 20, and 21, 
these rejections are respectfully traversed. 
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II. Rejections Under 35 U.S.C. § 112, First Paragraph 

The Office Action rejected claims 1-19, 20-26, and 21-31 under 35 U.S.C. § 1 12, first 
paragraph, indicating that the claimed invention is unsupported by either an asserted utility or 
a well . established utility such that one skilled in the art would not know how to use the 
claimed invention. Office Action, p. 3. 

In view of the amendments to independent claims 1, 20, and 21, and the remarks 
above regarding the 35 U.S.C. § 101 rejections, the rejections under 35 U.S.C. § 1 12 are 
respectfully traversed. 

Assignee also notes that the application asserts at least one utility, indicating that a 
"query may use the account and/or account involvement entity classes to determine which 
customer is associated with the specified account in order to retrieve information." 
Application at If 0089. In addition, the application indicates that the "user interface module 
110 generally includes a self-contained language ('SQL') or a host language or legacy 
system for communicating with the database system 130." Application at K 0044. Thus, the 
application provides support for claims 1-19, 20-26, and 27-31, which describe statutory 
subject matter sufficiently such that a person skilled in the art clearly would know how to use 
the claimed invention and would readily understand that the claims have a credible utility for 
enhanced functionality of a database and information retrieval system. Moreover, the 
application discloses that the claimed invention is applicable to support, for example, the 
database and information retrieval system for an insurance underwriting workflow system. 
Application at Tit 0002, 0006, 0071, and 0080-0087. Accordingly, Assignee submits the 
claimed inventions have either an asserted utility or a well established utility. 

m. Rejections Under 35 U.S.C. § 103(a) 

The Office Action rejected claims 1-12, 20, and 22-26 under 35 U.S.C. § 103(a) as being 
unpatentable over Dimitrios et al. (U.S. patent 5,695,723) in view of Kennedy et al. (U.S. patent 
application publication 2003/0187826 Al). Office Action, p. 3. 

As an initial matter, Assignee notes that the data structure recited in claims 1-31 
provides functionality to capture recursive relationships derived from complex business 
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structures of customers (e.g., joint ventures, a customer with multiple accounts, and a single 
account with multiple customers) that Dimitrios, in view of any combination of Kennedy, 
Ariathurai or Moore does not teach, suggest, or disclosure. The data structure of claims 1-31 
provides the ability to organize members of a joint venture under a single account (e.g., 
policy), under which the members may have common policies separate from their respective 
individual policies. For example, where a joint venture exists between two companies (e.g., 
Yellow and Blue), an account (e.g., Green), which is made up Yellow and Blue, can be 
created. However, an account manager may already have separate accounts set up for 
Yellow and for Blue. As a result, the account manager may want to be able to create one 
master account (e.g., an account group), Green, which represents a grouping of the two 
already-existing Yellow and Blue accounts. Using the account entity and the account group 
entities in the account entity class the account manager may create the Green account. See 
FIG. 5 and FIG. 3, reference numbers 302, 304 and 210, and the Application at ^ 01 14. The 
data structure of claims 1-31 captures a joint venture relationship so that members of a joint 
venture that have a common account can be identified efficiently. Similarly, the data 
structure of claims 1-31 captures a customer with multiple accounts and a single account 
with multiple customers. The data structure of claims 1-31 provides an efficient and 
effective way to perform account level decision analysis. 

Claims 1 and 20 

With respect to independent claims 1, and 20, the Office Action indicates that Dimitrios 
discloses a data structure comprising: an account entity class, a customer entity class, an 
account involvement entity class, and account involvements. See Office Action, pp. 3-4. 
Assignee respectfully traverses these rejections. Dimitrios discloses that "'Account' is the 
target entity in the 'has a' relationship and account becomes an instance variable of the class 
of objects called 'customer' in Table 2." Dimitrios at col. 11, 11. 9-12. In other words, in 
Dimitrios each account has one relationship to only one customer. Dimitrios does NOT 
teach, suggest, or disclose an account having a relationship with multiple customers. 

Furthermore, the Office Action acknowledges that Dimitrios does not disclose an 
account role entity, and attempts to fill in the gaps with Kennedy. Office Action, p. 5. 
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Kennedy discloses "a role class" and indicates that a work record is assigned a role class. 
See Kennedy at ^ 0101 - 0102. Kennedy indicates that "each work record will have only 
one workflow and one role class." Kennedy at U 0101. Kennedy describes an invention 
"operable to automatically interoperate workflows of different work records that relate to the 
same original account, even if the different work records have different role classes." 
Kennedy at If 0103. In other words, Kennedy describes defining roles for work records NOT 
roles for customers. In contrast to claims 1 and 20, Kennedy does not teach, suggest, or 
disclose establishing multiple different roles for a customer with respect to multiple 
different accounts or establishing multiple different customers with different roles with 
respect to an account. 

"In the database, a participant is created by associating a customer data object with an 
account data object in the account involvement entity (see FIG. 5, reference number 502), 
and defining a role for the customer with regard to the relationship (see FIG. 5, reference 
number 504). It is possible for a customer to have multiple roles in a single relationship or 
across many relationships. Roles may include insured, driver, contact, agent, etc." 
Application at J 0092. 

Accordingly, Dimitrios in combination with Kennedy do not teach, suggest, or 
disclose the formation of multiple concise account level decision relationships with the 
account entity class, the customer entity class, the account involvement entity class, the 
account involvements, and the account role entity class used to construct multiple concise 
account level decision queries used to perform account level decision analysis, as recited in 
claims 1 and 20. Thus, the rejection of independent claims 1 and 20, and the claims 
dependent therefrom, claims 2-19, and 22-26, should be withdrawn. 

Claims 10 and 12 

The Office Action rejected claims 10 and 12, under 35 U.S.C. § 103(a), as being 
unpatentable over Dimitrios in view of Kennedy. Office Action, p. 8. The Office Action 
indicates that Dimitrios disclose a data structure, "wherein the customer involvement entity 
class includes a customer role entity that defines a customer role for customer data objects." 
Office Action, p. 8. However, the Assignee's undersigned representative is unable to 
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identify where Dimitrios discloses a customer role entity. Even so, the Office Action 
contends that Kennedy discloses a data structure, wherein a role entity defines a role for a 
customer data object. Office Action, p. 9. Kennedy recites "each work record will have only 
one workflow and one role class." Kennedy at ^ 0101. The Dimitrios-Kennedy combination 
discloses roles assigned to work records related to accounts. 

Assignee traverses this rejection since the Dimitrios-Kennedy combination fails to 
teach, or suggest establishing either multiple different roles for a customer with respect to a 
single account or multiple different customers with different roles with respect to a single 
account. Even assuming motivation to make the Dimitrios-Kennedy combination, the 
combination does not disclose the features present in claims 10 and 12 with base claim 1, 
defining multiple account roles and multiple customer roles assigned to a single customer 
data object. The features present in claims 10 and 12, for example, allow a customer role of 
"employer or employee" to be assigned to a customer data object, while the same customer 
data object maybe assigned the account role of "insured, primary contact, or household 
member," without regard to the account ownership status of the customer data object. In 
contrast to the assertion in the rejection of these claims, Assignee submits that this feature in 
claims 10 and 12 are not taught by Kennedy. Rather, the cited portions of Kennedy teach 
roles assigned to work records related to accounts. 

Claims 13-19 

The Office Action rejected claims 13-19, under U.S.C. § 103(a) as being unpatentable 
over Dimitrios in view of Kennedy and further in view of Ariathurai (U.S. patent application 
publication 2002/0198743 Al). Office Action, p. 11. 

With respect to claims 13-19, the Office Action indicates that Dimitrios failed to 
explicitly disclose an offering entity class, a service entity class, a program entity class, a 
provider entity class, and a task entity class, and the Office Action attempts to use Ariathurai to 
fill in the gaps. See Office Action, p. 1 1-14. The Assignee respectfully traverses this 
rejection. Although Ariathurai discloses using a tool to "relationally store data" and 
"relationally organize" data, Ariathurai does NOT define a relationship between an offering 
entity class, a service entity class, a program entity class, a provider entity class, and a task 
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entity class. Instead, Ariathurai merely indicates that it has a database that "includes a set of 
related database tables which store information related to all aspects of the insurance 
underwriting process, including customer information, policy information, invoice and 
billing information and accounting information." See Ariathurai at fflf 0019, 0043, 0044, 
01 12, 01 14, and 0123. Even assuming motivation to make the Dimitrios-Kennedy- 
Ariathurai combination, the Dimitrios-Kennedy-Ariathurai combination does not disclose the 
features in claims 13-19, with base claim 1, wherein multiple roles are assigned to a 
customer in multiple accounts, and multiple customers in an account. 

Claims 21 and 27-31 

The Office Action rejected claims 21, and 27-31 under U.S.C. § 103(a) as being 
unpatentable over Dimitrios in view of Kennedy and further in view of Moore (U.S. Patent 
5,446,885). Office Action, p. 14. 

With respect to independent claim 21, the Office Action indicates that neither Dimitrios 
nor Kennedy explicitly disclose providing a first entity class for establishing multiple risk data 
objects. See Office Action, pp 15-16. The Office Action attempts to fill in the gaps of the 
Dimitrios-Kennedy combination with Moore. See Office Action, p. 16. Moore is directed to 
an invention that "performs risks and exposure calculations (both mathematical and logical) 
for the institution based upon the institution's risk and exposure rules." Moore at col. 2, 11. 5- 
10. 

In contrast to Moore, claim 21 recites "establishing multiple different account roles 
for a customer identified by the first customer ID with respect to multiple different accounts 
identified by the first account ID and the second account ID; a third account role for the 
second customer data object, for establishing multiple different customer IDs, the first 
customer ID and the second customer ID, with different roles with respect to the second 
account ID; and a fourth account role for the first customer data object with respect to the 
first account ID, the fourth account role different from the first account role, for establishing 
multiple different roles for the customer identified by the first customer ID with respect to 
the account ID identified by the first account ID; providing a first entity class for 
establishing: multiple risk data objects; multiple product data objects; and multiple service 
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data objects; providing a second entity class for establishing: relationships between the risk 
data objects, the account data objects, the customer data objects, the product data objects and 
the service data objects." In contrast to claim 21, similar to the arguments with regard to 
claim 1 , Dimitrios, even in combination with Kennedy and Moore, does not teach or provide 
motivation for defining table structures and relationships establishing multiple different 
roles for a customer with respect to multiple different accounts or establishing multiple 
different customers with different roles with respect to an account, and multiple risk factors 
related to accounts, customers, products or services. Accordingly, the rejection of claim 21 
and its dependent claims 27-3 1 should be withdrawn. 

For at least the foregoing reasons, Dimitrios, in view of any combination of Kennedy, 
Ariathurai or Moore, does not teach or suggest each and every limitation of independent 
claims 1, 20 and 21, or the claims dependent therefrom. Thus, the presently pending claims 
are allowable over the cited references. Accordingly, Assignee respectfully requests that the 
claim rejections under 35 U.S.C. § 103(a) be withdrawn. 

Conclusion 

In view of the above remarks, Assignee respectfully submits that this application is in 
condition for allowance and such action is earnestly requested. If for any reason the 
Application is not allowable, the examiner is requested to contact the Assignee's undersigned 
attorney at (312) 321-4200. 
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